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Quality of Service Monitoring Architecture , related 
Method, Network and Computer Program Product 

* * * 

5 Field of the Invention 

The present invention relates to techniques for 
monitoring Quality of Services (QoS) in 

telecommunication networks. The invention was developed 
with particular attention to its possible application 
10 to mobile communication network. However, reference to 
this particular field of possible application must not 
be construed as limiting the scope of the invention. 

Description of the Prior Art 

With the emergence and development of mobile 
15 networks, from GSM to GPRS and, more recently, to UMTS, 
the variety and the number of voice, data, multimedia 
services available or emerging in this field is growing 
both in terms of functional characteristics, and in 
regard to performance requirements, to meet needs 
20 expressed by the user or deriving from an ever more 
competitive market. 

For a provider of mobile services, being able to 
obtain a qualitative benchmark on its services is 
increasingly becoming a factor for success and market 
25 penetration, as well as for containing w churn" 
phenomena, with important repercussions on revenues. 

The fundamental needs of the service provider, to 
achieve qualitative benchmarking, are essentially 
linked to the ability to: 

30 

objectively evaluate and manage Quality of 
Service (QoS) in a manner that is as close as possible 
to subjective perception, 
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- measure QoS in systematic fashion, focused on 
the sources of critical situations or degradation, and 

evaluating QoS levels in a manner that is 
comparable with other operators . 

5 

All this with the additional requirement of being 
able to perform the measurements at low cost . The 
service provider must therefore have available QoS and 
performance data that are : 

10 - systematic, with accurate and reliable data, in 

order to monitor the offered quality levels (referred 
to application sessions) , 

punctual, to highlight quality degradation 
(which can be associated to the user and to the 
15 involved communication, and related cause and location 
information) , able to facilitate and drive 
troubleshooting and improvement activities, and to make 
them more timely and effective, 

- specific, with data capable of being used not 
20 only for planning purposes, but also for a real time 

optimisation of the configuration and management of 
network resources (radio access and core) and for 
comparison with other operators to face the 
competition. 

25 For a user of mobile services, being able to 

achieve high quality levels during a communication, 
having objective documentation of the quality and 
operational levels in relation to the underwritten 
agreements (SLA), is not just a requirement, but is a 

30 guarantee of transparency and an image factor of the 
service provider which increases his/her satisfaction 
and hence his/her loyalty to the service provider. 

The complexity and heterogeneity of the mobile 
radio network environment (limited capacity of radio 
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resources, mobility, integration with fixed networks, 
limited dimensions of the screen and keyboard of the 
terminal, etc.) and of the services offered therein 

(e.g. localisation, MMS, video streaming, multimedia) 
5 make it difficult to obtain an accurate and punctual 
measurement of the dynamically variable quality levels 
experienced during a communication. This is also true 
because, in addition to being referred to reference 
agreement underwritten with the user, said quality 
10 levels depend on an ever more complex management based 
on differentiated service and traffic classes 

(conversational, streaming, interactive, background see 
for instance 3GPP TS 23.107) with dynamic control and 
differentiated and sophisticated stream management 
15 (3GPP TS 23.207), in terms of guaranteed quality 

(requested) and of priority (RSVP, DiffServ, etc.). 

An objective, systematic and punctual evaluation . 
of the quality of service provided, adhering as closely 
as possible to the quality perceived by the user and 

20 which can be used not just by the service 
provider /operator, but also by the user him/herself, 
increasingly leads to decentralise the measuring and 
performance monitoring points in the points of access 
at the ends of the link (user terminal and application 

25 servers) and in the user- terminal application 
interaction (application level or highest possible 
protocol layer) . 

Heretofore, the methodologies and techniques in 
use have fundamentally been based: 

30 - on QoS measurement and management techniques 

based on terminal and network measurements which are 
typical of the quality and operating conditions of 
radio access, used also for the optimised management of 
handovers and of radio resources, such as measurements 
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interference on uplink and downlink channels, often, 
though erroneously, called QoS measurements (see for 
example WO-A-Ol/19114 and US-A-6 449 464) . These 
5 measurements indirectly increase the offered quality 
level, but are not capable of directly evaluating it in 
the quantitative and qualitative sense in relation to 
the quality perceived by the user; 

- on monitoring, under actual traffic conditions, 
10 the performance of shared network and link resources at 

the transport level (normally carried out by the mobile 
radio operator with internal or external measures, 
taken by sampling or total with counter, but almost 
never inclusive of the terminal and hence not end- to- 

15 end and not at application level) , with evident limits 
to the ability to correlate said measures to the 
communication quality actually perceived by the user, 
al so deriving from the difficulty of activating co- 
ordinated measuring campaigns in the network on a call 

20 and/or service session basis; 

on measurement campaigns under artificial 
traffic conditions, conducted using terminals and/or 
specialised equipment (whose characteristics are not 
always equivalent to the commercial mobile radio 

25 terminals utilised by users) , with obvious deficiencies 
from the viewpoint of flexibility and accuracy, and 
with high costs, due to the continuous employment of 
specialised personnel and to the additional generated 
traffic (see for example US Patent Applications US 

30 2001/0041566, US 2002/0077786, US 2002/0015398 and also 
WO-A-01/72058) ; and/or 

- on QoS control techniques implemented through 
the dynamic management of network resources, able to be 
adapted to the requirements of the requested service or 

35 services, as described for example in US Patent 
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Applications US 2002/0141446, US 2003/0112766 and US 
2002/0181394) . 


Examining in detail some recent contributions on 
5 this subject, the Patent US-A-6 434 364 describes a 
communication system that supports mobile test software 
agents (MTSA) . The applicant observes that this system, 
in addition to being based only on the GSM network, has 
several limitations linked to measurement types and to 

10 measurable parameters. In particular, it is impossible 
to obtain qualitative parameters of the application 
session (delays, jitter, losses...)/ or performance 
parameters referred to the operating conditions of the 
session (link throughput, CPU and memory utilisation 

15 level, terminal buffer congestion). The system does not 
provide for quality measurements on the application 
session, but only performance measurements on the radio 
channel at the low transport layers. The whole 
operation of the monitoring system is integrated in the 

20 functionalities of the network, i.e. it uses all normal 
functionalities of mobile radio networks. This entails 
problems with using the platform in multi -standard 
environments. Moreover, this system is incapable of 
adapting to the load conditions of the network and of 

25 the terminal . 

One can also mention the commercial product 
QualiPoc of the company SwissQual AG, Zuchwill CH: this 
is a system that operates only in artificial traffic in 
which terminal configuration is done manually, loading 
30 the monitoring software; it does not allow to configure 
the measurements made, or to configure measurement 
procedures. It does not monitor the terminal and/or 
network resources in use; the measurements are 
downloaded locally, with no chance to integrate the 
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system with other monitoring platforms; it is only 
available for the MMS service. 

Aims and Summary of the Present Invention 
The object of the present invention is to solve 
5 the critical aspects of the solutions identified above. 

According to the present invention, said object is 
achieved thanks to an architecture for monitoring 
quality of service having the characteristics 
specifically described in the claims that follow. The 

10 invention also pertains to the related network, a 
corresponding method and a computer product able to be 
loaded into the memory of at least an electronic 
computer and comprising portions of software code for 
implementing the architecture and/or the method 

15 according to the invention when the product is executed 
on an electronic computer. Reference to an electronic 
computer is clearly destined to highlight the 
possibility of implementing the solution according to 
the invention at a decentralised level. 

20 The currently preferred embodiment of the 

invention thus allows to obtain an architecture for 
monitoring Quality of Service (QoS) in a 
telecommunication network comprising a set of 
terminals. The terminals of the aforesaid set house 

25 measuring agents which can be configured to interface 
with processes selected among processes for managing 
the application sessions of said network and processes 
for measuring the operating conditions of the network 
itself. Also provided is a management and configuration 

30 sub- system comprising a module for scheduling Quality 
of Service measuring campaigns, capable of involving 
respective sub-sets of terminals according to a set of 
characteristics identifying the measuring campaign. The 
scheduling module is able to configure, for the 

35 purposes of the execution of the aforesaid measuring 
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campaigns, the measuring agents housed by the terminals 
included in said related sub-sets according to said set 
of identifying characteristics. 

Advantageously, an additional subsystem for 
5 managing the collection of the measurement data is also 
provided, preferably comprising a database for storing 
the measurement data and a processing centre for 
processing the data itself. 

In the currently preferred embodiment, the 
10 solution described herein overcomes the critical issues 
intrinsically linked to the solutions identified above 
with particular reference to one or more of the 
following operating aspects: 

types of measures which can be conducted 
15 (qualitative, performance-related) , 

- type of measurement (artificial traffic, real 
traffic) , 

- possibility of conducting measurements by means 
of software agents with no need for ad hoc hardware, 

20 - ability to remotely configure the measurements 

dynamically, 

- ability to choose the terminals, with remotely 
programmable and schedulable activation of the 
measurements , 

25 - modes of transporting configuration commands and 

data: for instance, SMS, TCP/IP, UDP etc. directly 
using the radio channel, 

- measurable parameters: quality (delay, jitter, 
losses at the session level) , performance -related 

30 (delay, throughput, losses at the transport level), 
parameters characterising terminal and network 
operating conditions, 

- location of the physical point of measure 
(terminal, PC, system, node), 
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- location of the logic point of measure (protocol 
layer) : e.g. low layers (physical, link) , 

- location of the terminal during the measurement, 

depth of the measurement (end-to-end and on 
5 individual call for an individual user) , 

- ability to perform quality measurements in the 
point nearest the user and on the application (for 
example, in the case audio-video-data multimedia 
service, it is possible to perform differentiated 

10 quality measures for individual media and for 
correlation between them, for instance measurements of 
synchronisation between audio and video) , 

modes of transporting and collecting the 
measurement results: "report result message" (for 
15 example, transported on a normal radio channel) , 

adaptability of the characteristics of the 
measurement to the type and number of the sample of 
terminals which can be activated, 

adaptability of processing, management, 
20 collection of the measurements to the operating 
conditions of the terminal and of the network, 

independence from the operating contexts 
deriving from the type of network (for instance mobile 
radio) , from the type of service, from the type of 
25 terminal and from the specific network functionality 
(handshake, roaming, location, etc.), 

- ease of extension to new services/applications, 

- flexibility (independence from type, resources, 
technologies used in the link) , 

30 - stability (in case of changes/evolutions in the 

network) , 

ease of interfacing with other performance 
measuring/monitoring systems, 

- security/reliability of measurement data, 
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- partitioning of homogeneous performance/quality 
measurements on the link, and 

ability to correlate quality and transport 
performance measurements. 

5 The system described herein can be configured in 

such a way as to assure the functionalities described 
above in simultaneous and co-ordinated fashion, 
although a subset of such functionalities can be 
implemented, without thereby departing from the scope 
10 of the invention described herein. 

In general, the invention, in addition to allowing 
an integrated, detailed and accurate vision of the 
quality levels, can allow both to relate the quality* 
levels to the operating conditions in which said 
15 quality levels have been reached, and to correlate 
quality and performance parameters (e.g. between levels 
of quality/power of the radio channel and dropped 
communications) . 

20 The system, which is scaleable and modular, 

excellently meets the requirements of security and 
reliability of the measured data, functional and 
performance transparency (i.e., non intrusive nature) 
with respect to the terminal and the user and economic 

25 transparency with respect to the service to be 
measured. 

Brief Description of the Accompanying Drawings 

The invention shall now be described, purely by 
30 way of non limiting example, with reference to the 
accompanying drawings, in which: 

Figure 1 is a function block diagram 
illustrating the platform architecture described 
herein, 
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- Figure 2 is a diagram illustrating the flow of 
the interactions for use of the aforesaid platform, 

Figure 3 is a diagram illustrating the 
functional steps of activating and executing a measure 
5 at a peripheral agent with subsequent downloading of 
the measurement into a collection centre within the 
platform of Figure 1, and 

- Figure 4 is yet another functional block diagram 
showing the possible types of use of the platform 

10 described herein, seen from the terminal side. 

Detailed Description of Embodiments of the 
Invention 

Figure 1 shows the general architecture of the 
system described herein, highlighting the function 
15 modules which compose it and the location of the 
communication and measurement agents. Also indicated 
are the external interactions both from/to a user of 
the system and to external systems for the collection, 
analysis, reporting of the results. 

20 Briefly, referring to the (preferred, but not 

imperative) application to a mobile communication 
network - according to any standard - at the mobile 
terminal MT level the following are provided: 

- a measuring agent MEA (Measurement Executor 
25 Agent) , 

- a Measurement Elaboration Module (MEM) , and 

- a Communication Agent CA1 . 

At the level of the management and configuration 
system, overseeing the measurements (indicated herein 
30 as TQMS, with reference to the typical role of the 
Terminal Quality Measurement Scheduler) are instead 
present : 
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~ a measurement campaign scheduler S, 

- a communication agent CA2 , and 

- an interface Al for interfacing with a user of 
the system. 

At the subsystem level having the function of 
managing data collection (Terminal Data Collector 
Manager or TDCM) , are present : 

- a database DB, 

- a processing centre EC, 

- a collection centre CC, 

- a communication agent CA3 , and 

*■ 

- an interface A2 for interfacing between the 
platform and any external systems. 

The dialogue between the various architecture 
15 components described (it will be noted that the 
structure illustrated with reference to the mobile 
terminal TM is usually reproduced at the level of 
multiple mobile terminals - and virtually at the level 
of all the mobile terminals of the network) is assured 
20 by the communication agents CA1, CA2 and CA3 . 

The agent CA2 associated to the management and 
configuration subsystem TQMS usually performs the role 
of co-ordination node, although - especially for the 
exchange of measurement data - direct communication is 

25 provided between mobile terminals TM and the manager 
module TDCM (and, possibly, between mobile terminal and 
mobile terminal) . In particular, in the diagram of 
Figure 1 the data lines and the signalling lines are 
respectively represented with solid lines and with 

30 dashed lines. 
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The user is able to co-ordinate with the TQMS 
subsystem to obtain joint simultaneous measurements. 

Although it is not explicitly indicated in the 
figure, the measurement functionalities implemented on 
5 the terminal are also usable on the application 
servers. The TQMS and TDCM subsystems are thus able to 
interact with the agents located on the servers. 

The architecture described herein defines and 
implements a system for monitoring the end-to-end QoS 
10 at the application layer in which the elementary 
measurements are effected by means of agents located 
directly on the TM terminal (and on the application 
server) , in a manner that is transparent to the user. 

The present description is centred on wireless 
15 networks/services, simply because it is the most 
stringent environment in terms of requirements and 
resource availability, especially at the terminal level 
(in terms of CPU and memories) and at the link level, 
where channel throughput is limited by radio access. 
20 The system can easily be extended to services 
(fundamentally, data) which employ wireline networks or 
to services on mixed wireless and wireline links, with 
terminals, be they cellular phones or PCs, connected 
both in wireless and wireline fashion to the network. 

25 The basic system can be developed to cover 

diversified uses of considerable interest both for the 
service provider and for the user. 

The service provider can use the system to perform 
systematic measurements, to activate focused or 
30 troubleshooting measurements or measurements for 
verifying SLAs stipulated with the user. The system 
enables the service provider, above all by means of 
simultaneous measurements on the same samples of calls, 
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to conduct both segmented analyses of contributors to 
degradation on the link (to ascribe the causes, for 
example, to the terminal rather than to the application 
server or to the network) , and analyses of correlation 
5 between homogeneous parameters measured between 
different protocol levels (e.g. between transport level 
and application level) . 

If the user is enabled and authorised, (s)he is 
able to activate the measurements and to display, 
10 directly on the screen of the terminal of the 
management and configuration subsystem TQMS (through a 
GUI graphic interface) the quality levels obtained for 
the communication, or to conduct SLA verifications by a 
highlighted comparison with stipulated levels. 

15 If the degradation contribution is located in the 

terminal (or in the application server) , local 
diagnostic investigations are possible with ad hoc 
measurements which can be obtained through the system 
itself. All these measurements, together with others on 

20 the radio channel and location on the terminal, allow 
opt imi sat ion/reconf igurat ion operat ions , especial ly on 
the radio access system, or short/medium term cell re- 
planning. 

The measurements can be performed both in real 
25 traffic on the communications activated by the user, 
and in artificial traffic driven from the network when 
the cell phone is in the idle state or the mobile radio 
terminal is not already performing the same type of 
service to be activated for the measurement. 
30 Measurements in real traffic can be activated also by 
the user for the ongoing communication. All 
measurements are configurable (among possible ones) by 
the network (remotely through the scheduler) or by the 
user (on the terminal) . 
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The measuring agent MEA on the terminal TM 
interacts with the application process for carrying out 
the service, as well as with the processes for 
measuring the mobile radio channel used, and with the 
5 operating processes within the terminal itself. In this 
way, the following measurements can be performed: 

- quality level of the service at the application 
layer (availability, accessibility, link drop, delay, 
loss, integrity of the information content, such as 

10 those set out in the specification 3 GPP TS 23.207), 

- power and quality of the radio channel (BER, 
interference. . . ) used, 

- performance characteristics of the end-to-end 
connection (throughput) , 

15 - terminal status and location, 

the simultaneous operating conditions of the 
terminal (or of the server) (CPU usage, memory usage, 
buffer saturation, etc.). 

The agents on the terminal, in addition to 
20 performing measurement interactions, also perform 
processing and storing functions (MEM agent) and 
communication functions (CA1 agent) . These activities 
are performing minimising their impact both on the 
resources of the mobile terminal and of the network, in 
25 order to meet the non- intrusion requirement of the 
platform described herein. 

Preferably, for the management /configuration of the 
services provided by the agents and communication 
between agents, Jade technology is used (Jade is JAVA 
30 Agent Development Framework, as described for example 
in "A communication Protocol for agent on hand held 
devices" AAMAS 2002, July 15-16 Bologna, Italy), which 
allows the development of distributed peer-to-peer 
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application developed in JAVA and compliant with the 
FIPA standard. The technology, usable both in fixed 
networks (JAVA J2EE and J2SE) and mobile networks 
(Personal Java and J2ME) and the related features 
5 (white pages, yellow pages) are used in agent 
management . 

This choice is not binding for the operation of the 
platform described herein because Jade could be 
replaced by other agent communication middleware. 

10 Communication between the agents can use different 
transport techniques selectable according to the 
operating conditions noted (for example if it is not 
possible to set up a TCP/IP link on GPRS because it is 
unavailable, the platform can decide to use transport 

15 on SMS) . Preferably, for the exchange of messages 
between agents, the TCP/IP or UDP/IP transports will be 
used. This capability can enable interactions between 
the modules of the platform even if, though 
electromagnetic coverage is present, the user is unable 

20 to access the service (for example in the case of UMTS 
network a user may not be able to access a high bit 
rate video streaming services and, simultaneously, the 
agents on the terminal can, selecting an appropriate 
transport, send and receive data to and from the other 

25 modules of the platform) . 

The scheduling and overall management policies of 
distributed Jade agents (anomaly detection and 
management, configurations and reconfigurations, 
measurement scheduling, etc..) are implemented by a 
30 central unit developed according to the work- flow 
paradigm. The general architecture of the platform 
described herein highlights the functional modules and 
the interactions between them. Hereinafter reference 
shall be made to an u abstract" entity called User which 
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can be either a human operator or an external program, 
able to interact with the platform. 

The functionalities of the function modules 
identified above are described in greater detail below. 

5 Scheduler (TQMS) 

The measurement campaign scheduler designated as S 
is tasked with defining measurement campaigns. For this 
purpose the user interacts with the scheduler (through 
the interface Al) defining the characteristics of the 
10 measurement campaign (the reference universe) . 

This operation comprises multiple steps: 

- defining the fundamental characteristics of a 
measurement campaign, able to identify the terminals to 
be subjected to the campaign (users, agreed contractual 

15 profile, service, terminal, spatial elements) , 

- defining the measurements to be made and the QoS 
indices to be obtained (compatible with the fundamental 
characteristics) , 

- defining the characteristics of the measurements 
20 to be made (measurement frequency, mode of sending the 

measurements to the collection centre) , and 

- defining the contextual information, associated 
to the measurements, that the peripheral agents will 
have to send together with the values of the 

25 measurements (type of measurement, information on the 
status of the terminal and of the network, . . .) . 

To identify the involved terminals and activate the 
measurements the scheduler identifies potential 
terminals involved in the defined measurement campaign, 

30 proceeding to activate them. During the initial step, 
mechanism preferably intervenes to optimise the final 
transmission of the information to the TDCM in w a 
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single shot" : a method which can be used to optimise 
communications is DB sharing, where the scheduler 
stores the information about the involved terminals, 
their status and the measurement profiles loaded on the 
5 terminal . 

The operation of identifying the terminals and 
activating the measurements comprises the following 
steps : 

- the continuous search for the terminals that 
10 correspond to the fundamental characteristics, 

throughout the duration of the campaign, 

- for each identified terminal, the scheduler S: 

- records the terminal on internal data base 
(signalling to the user) , 

15 - creates the measurement profile with all 

information for managing, carrying out, processing 
and sending the measurements by the peripheral 
agent , 

- transfers the measurement profile created 
20 by the peripheral agent (if the peripheral agent 

does not have a valid one, sent previously) , 

- activates the campaign on the terminal, 

- sends information on the involved terminal 
and the list of the expected measurements to the 

25 TDCM subsystem, together with the parameters of the 

elementary campaign; 

- identifying the terminals that undergo changes to 
the fundamental characteristics required by the 
campaign, making them non conforming therewith. For 
30 these terminals, the scheduler: 

- deactivates the campaign on the terminals, 

decides whether or not to delete the 
measurement profile of the terminal, 
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- informs the TDCM subsystem. 

To identify the end of a measurement campaign, the 
scheduler S identifies for instance the expiration of a 
time-out) . When this event takes place, for each 
5 terminal that was involved in the campaign, the 
scheduler S : 

- deactivates the campaign on the terminals, 

- decides whether or not to delete the measurement 
profile of the terminal, 

10 - informs the TDCM manager of the end of the 

measurement campaign. 

The Al interface represents the communication 
element towards the other external systems for the 
configuration and synchronisation of the measurement 
15 campaign, in particular to detect configuration 
commands from the exterior and communicate the updated 
information on the status of the campaign. 

The interface preferably has available the 
functionalities to: 

20 - define a measurement campaign, 

- configure a measurement campaign, 

- command the activation of a measurement campaign, 

- monitor the status of a measurement campaign, and 

managing the time synchronisation of a 
25 measurement campaign. 

The main functionalities of the communication agent 
CA1 associated with the terminals TM are: 

detecting the configuration commands by the 
scheduler S, 

30 - regularly informing the scheduler S of its own 

status (operating environment of the agent) , 
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- interacting with the other terminals, 

- activating the measurements processing agent MEM, 

receiving the data from the measurements 
processing agent MEM, 

5 - sending the data to the collection centre CCC, 

- receiving software from the TQMS subsystem during 
the configuration step (for example software relating 
to the MEM and/or MEA agents) . 

The main functionalities of the subsystem 
10 constituting the MEM agent are: 

- detecting configuration commands by the scheduler 
(through the communication agent) , 

recognising the network/terminal status and 
"adapting" the way the measurements are conducted, 

15 - conducting measurements at regular intervals on: 

- the load state of the terminal TM and/or of 
the network, 

- the radio resources used by the terminal TM 
for the activated services, 

20 - location information, 

being able to adapt the processing, 
aggregation and/or transmission of the measurements 
based on the network/ terminal state acting on 
parameters such as, for instance: 
25 - measurement times, 

- measurement aggregation, 

- measurement processing algorithms, 

- transmission time and procedure; 

- informing the scheduler S (at regular intervals) 
30 of state/position, and 

- signalling any malfunction events. 
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The subsystems constituting the measuring agent MEA 
carries out the measurements and therefore must be 
configured, on each occasion, according to the 
requirements of the campaign. To maximise flexibility, 
5 this portion of code can be completely or partially 
transferred, from the scheduler, to the terminal. 

The main functionalities of this subsystem, once it 
i s conf igur ed , are : 

- detecting and recording the contextual data of 
the measurement, 

- obtaining the mobile radio system measurements 
(this depends on the terminal) such as: 

- radio system measurements and/or events of 
the terminal like power, radio quality, handover; 

- obtaining terminal state measurements, such as: 

- detecting that the terminal has been turned 

on, 

- battery level, 

- CPU usage level, 

- memory usage level, 

. . • • 

Note that the peripheral measurement agents MEA, to 
conduct service measurements, must detect events of the 
service of interest (e.g. opening a session, requesting 
25 and receiving data, etc.) . 

In alternative embodiments, the peripheral agents 
MEA and MEM can also be located on the application 
servers (servers involved in the provision of the 
service) for the various types of services. 

30 They can also be located on a certain number of 

terminals having different performance characteristics 
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and/or they can interact directly with each other to 
implement functions to be analysed (e.g. the terminals 
which are within the same cell could co-ordinate with 
each other to transmit the measurements to the 
5 collection centre, avoiding the simultaneous use of the 
radio resources) . 

Preferably, each peripheral agent interfaces with: 

- the operating system of the terminal, 

- the application through which the user accesses 
10 the service, 

the communication software (both at the 
application level and at the network level) , 

- the software which is stored on the SimCards and, 
possibly, with their operating system. 

15 Typically, a peripheral agent of the platform 

interacts with other processes through API interfaces 
(Application Programming Interface) which can be: 

- standard of the programming language used (in the 
example described herein, Java) , 

20 - specific of the platform used to manage the 

processes of the platform and for communication between 
the peripheral and the centralised agents, 

- specifications of the operating system of the 
terminal (e.g. Symbian) , 

25 The API interfaces for interfacing with the 

applications (for example for interfacing with other 
environments such as JavaPhone, JavaCard etc.) are 
preferably accessible by the peripheral agents through 
a general API which uncouples the development of the 

30 peripheral agents from the operating and development 
environment . 
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The functionalities of the TDCM subsystem result 
from those of its constituting elements, as described 
below. 

In particular, the collecting centre CCC: 

5 - collects the measurement data arriving from the 

different terminals , 

- receives the records sent by the terminals, 

verifies semantic correctness (any errors 
introduced by the transport, missing measurement, 
10 partial measurement) , and: 

- in case of errors requests the terminal TM 
to retransmit the measurement (with error 
management function, possibly providing for the 
storage, for a certain period on the terminal, of 
15 the measurements made in order to retransmit them 

later) , 

if no errors are found, it sends the 
measurement data to the processing centre EC, 

The latter, when preparing the start of the 
20 measurement campaign, receives the configuration 
commands from the scheduler S. In this way the manager 
TDCM knows: 

the characteristics of the measurement 
campaign itself (limit duration, types of measurements, 
25 services, etc,)/ i.e. of the reference universe, 

- the list of potential terminals involved in 
the campaign, and 

- updates on the status of potential terminals. 
During the processing step, the centre EC reads 

30 the context data of each measurement arriving from the 
collection centre in order to: 
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- associate them to the measurement campaign 
and to verify their actual ability to be associated to 
the reference universe adopted by the measurement 
campaign itself, 

5 - recognise and check the sequential (time- 

related) order of the records, possibly recognise the 
last elementary measurement for that campaign, 

- send a notification to the user when one of 
the following events takes place: 

10 - updating of the number of measurements sent 

by each involved terminal, 

any errors detected on the peripheral 
agents (e.g. the expiration of a time-out 
regarding the recording of an event by the 

15 peripheral agent) , 

- recognise the end of the measurement campaign 
(in a manner synchronised with the scheduler S) . 

At the conclusion of a measurement campaign the 
20 TDCM manager subsystem applies a criteria to accept or 
reject the received measurements (for example those 
received after the logic conclusion of the campaign and 
pertaining to events started before the conclusion, or 
those that are still incomplete, ...) , processing the 
25 correct records with the procedures prescribed by the 
campaign itself and storing them in the database DB. 

Moreover, the manager TDCM stores the results and 
the reports on a database that is logically different 
from the one used to store the elementary measurements 
30 because time persistence may be different. 

The types of interaction between the modules of 
the platform described above can be classified 
according to at least two different criteria: 
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- use of the resources of the mobile radio system: 
this criterion aims to differentiate the interactions 
between processes depending on the use of the resources 
of the mobile radio network because they must be 

5 subject to different performance requirements, 

functional criterion: this criterion aims to 
highlight the differences between the "signalling" 
relationships between various entities of the platform 
and those which exchange data. 

10 For the interactions that pertain to the processes 

of the platform described herein, two other types of 
interactions should also be specified: 

- a "horizontal" type of interaction which groups 
all the interactions between processes of the platform; 

15 these can, in turn, be subdivided into two classes: 

- communication interaction: the interaction 
between two or more agents of the platform when 
they must exchange data (measurements, quality 
indicators, etc . ) , 

20 - management interaction: the interaction 

between two or more agents of the platform when 
they must exchange configuration data or when they 
. must perform management procedures (activation, 
cancellation, agent downloading) ; 

25 - a "vertical" type of interaction which groups 

all possible interactions between the processes of the 
platform and external processes such as the terminal 
operating system, the applications, the communication 
protocols, the data base management systems (DBMS) , 

30 etc 

In this regard, the functional diagram of Figure 2 
highlights the following types of interaction: 


WO 2005/048629 


PCTYIT2003/000743 


25 

configuration of the platform in view of a 
measurement campaign: this interaction, designated by 
the number 10, is typically a horizontal signalling 
interaction of the TQMS subsystem (more specifically, 
5 the scheduler S) to the peripheral agents housed on the 
mobile terminals TM, 

any request for measurement data from the 
peripheral agents (MEM in Figure 1) to a MEA type 
entity: this interaction, designated as 20 is typically 
10 a vertical signalling interaction which involves, for 
example, an HTTP client process, designated as CHP, 
with the aid of a web browser WB, 

- provision of the measurement data requested as a 
15 result of the interaction that has just been described: 

this interaction, designated as 30, is typically a 
vertical interaction of data transmission from the 
agent MEA to the agent MEM, and 

- transmission of the measurement data from the 
20 peripheral agents to the measurement collection 

subsystem TDCM (and to the management and configuration 
subsystem TQMS which co-operates with it) : this 
interaction, designated as 40, is typically a 
horizontal measurement interaction. 

25 A more detailed description follows of the 

fundamental operative steps for the use of the platform 
described herein which involve the normal 
functionalities of the various elements constituting 
the platform itself; specifically, a description will 

30 be provided of all possible cases of interaction 
between the platform elements referred to the design 
and development specifications of a practical 
implementation by the Applicant. 
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The description of the steps refers to the diagram 
of Figure 3 and applies to a context of measurement 
campaign performed by the platform itself through the 
interaction with an abstract entity called user. The 
5 user may be a person, an external process, an 
organisational entity or another element. It is evident 
that when the subject changes the implementations of 
the interface will change, but not the semantic aspects 
of the inter-relationships. 

10 In the example reproduced herein, it is assumed 

that the platform is interested in the following 
operations : 

- upon a user's subscription, the terminal is 
configured incorporating the communication agent and 
15 this action will make the terminals known to the 
platform itself by means of an identifier and 
correlated information; this information will be used 
to identify and locate the terminals ; 

- the user U interacts (step 100 of Figure 3) with 
20 the scheduler S defining the characteristics of the 
measurement campaign (the reference universe - whose 
status is notified to the user in a step 102) ; these 
characteristics may derive from planned systematic 
activities, from specific, internal monitoring 
25 requirements (e.g. customer base segments of particular 
interest) , or troubleshooting requirements of the 
network (e.g. when complaints are received); moreover, 
co-ordinated, synchronised measurement campaigns can be 
planned on homogeneous sets of quality parameters, to 
30 allow: 

correlations between objective network and 
service measurements on the same set of calls, 
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correlations between objective service 
measurements and subjective measures derived from 
surveys ; 

- the scheduler identifies the potential terminals 
5 involved in the measurement campaign; the result of 

this operation must be notified to the user who will 
have to decide whether to continue with the process and 
to express his consent in a step 104; in case of 
extensive and systematic campaigns involving a high 
10 number of terminals, it could become necessary to have 
an interface with the databases of the mobile radio 
network, to identify and locate the set of terminals 
potentially involved in the measurement; 

- the scheduler creates the measurement profiles 
15 (comprising information about the procedures for 

individual measurements and about the type of 
measurement and the inter-relationships between the 
measurements) suitable for each terminal involved in 
the measurement campaign; to the measurement profile is 
20 associated a criterion for timing the transmission of 
the measurements, to avoid any network overloads; 

- in a step 106, to each identified terminal is 
transferred the respective measurement profile (this 
procedure is noted by the peripheral agent - if active 

25 - in a step 108) ; the outcome of the operation is 
notified in a step 110 to the user: the user can then 
decide actually to carry out the measurement campaign 
(being able to choose whether to carry out the campaign 
only on those active at the start or also on potential 

30 ones - with the possible management of ongoing 
communications) ; 

- in case of consent by the user (expressed in a 
step 112) the scheduler automatically starts the 
measurement campaign on the configured terminals 

35 through a multicast command (when possible, the 
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synchronisation function between the scheduler , the 
peripheral agents and the TDCM, provided by the GPS 
system, could be used) , also preparing the list of 
potentially involved terminals and the list of 
5 measurements expected from each of them, and sending 
this information - in steps designated as 114 and 116 
in Figure 3 - to the TDCM subsystem together with the 
parameters of the elementary campaign; 

- during the measurement campaign, the scheduler S 
10 keeps track of the terminals potentially involved in 

the campaign; this information is used: 

- to activate and/or reactivate the campaign on 
the terminals which will be activated late with 
respect to the start of the campaign, 

15 - to suspend or deactivate the campaign on the 

terminals that, during the interval of the campaign 
itself, undergo changes to the parameters and/or 
the fundamental characteristics, 

- when processing the measurements, at the end 
20 of the campaign, to highlight any inconsistencies 

of the collected data relative to the scheduled 
data (measurements not carried out, partial, 
suspended due to terminal unavailability or 
overload, with errors; failed reception or 
25 integrity problems in the collection) ; 

- upon the activation, by the scheduler S, of the 
measurement campaign (step 118) , the peripheral agents 
start the prescribed measurements compatibly with the 
availability and/or load status of the terminal and of 

30 the network; 

- the peripheral agents store and pre-process the 
measurements locally to the terminal : this activity is 
set up in adaptive fashion by the peripheral agent 
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according to the measurement profile and to the 
performance of the terminal and of the network; 

- the peripheral agent sends to the TDCM subsystem 
(in a step 12 0) information records which comprise, in 

5 addition to the elementary measurements and/or to the 
calculated parameters, also context and operational 
data associated to the measurements; 

- the TDCM subsystem receives the records sent by 
the terminals and verifies their correctness (detecting 

10 any errors introduced by the transport, missing 
measurement, partial measurement) , feeding "back to the 
terminals in a step 122; in addition to confirming the 
reception (ACK) the feedback can bring the TDCM 
subsystem to request the terminal, in case of error, to 

15 retransmit the measurement (there must be provisions 
for the error management function must be provided for, 
possibly providing for the storage, for a certain 
period on the terminal, of the measurements made in 
order to retransmit them later) ; 

20 - the TDCM subsystem knows the list of potential 

terminals involved in the campaign, and the 
characteristics of the measurement campaign itself (the 
limit duration, the types of measurement, the services, 
etc.), i.e. of the reference universe, and it reads the 

25 context data of each measurement in order to: 

verify whether they can actually be 
associated to the reference universe adopted by the 
measurement campaign and, if so, it stores the 
elementary measurement and context data in the 
30 collecting DBs, 

- recognise and check the sequential (time- 
related) order of the records, and the last 
elementary measurement for that campaign, 
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- send a notification to the user when one of 
the following events occurs: 

- update the number of measurements sent 
by each involved terminal , 

5 - any errors detected on the peripheral 

agents (e.g. the expiration of a time-out 
pertaining to the recording of an event by the 
peripheral agent) , 

- of the measurement campaign; 

10 - at the conclusion of the measurement campaign, 

the TDCM applies a criterion to decide whether or not 
to accept the measurements received after the logical 
conclusion of the campaign pertaining to events which 
started before its conclusion; 

15 - at the conclusion of a campaign, in a step 124 

the TDCM subsystem (measurements processor) deactivates 
the measuring agents, processes the records corrected 
in the manners provided by the campaign itself, 
computes the quality indices and stores them in a DB 

20 that is logically different from that of the elementary 
measurements, since time persistence may be different; 

- the normal user of the platform is able to 
conduct specific queries on the DBs produced (on the 
overall set of the data from the various campaigns) , 

25 filtering QoS "Views" and sending the various report 
types to the interested corporate levels; 

- other users (e.g. belonging to the network 
area) , with authorised access profiles, can access the 
DBs of the Platform, with specific queries to filter 

30 data for correlation analysis and/or troubleshooting 
purposes (in this case, for more timely access, it will 
be necessary to provide dedicated areas on the 
collection data base where the results of the 
elementary measurements can be stored) . 
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The diagram of Figure 4 exemplifies some possible 
cases of use of the described platform. 

The QoS measurements thus obtained can be used by a 
mobile radio operator for different goals, for purposes 
5 of improvement in relation to internal processes and 
support systems, e.g. use of the system can be focused 
on the performance of the terminal under load to 
optimise its configuration or on communication quality 
or to perform troubleshooting analysis, and the user 
10 can be given the ability to control the functional and 
operational processes of the service of interest to 
him, e.g. to verify stipulated SLAs . 

The platform usage scenarios specifically 
identified herein relate firstly to Quality of Service 
15 monitoring, designated 200 in the diagram of Figure 4. 
This set of functions typically comprises: 

- measurements 2 02 carried out by the terminal (for 
instance, evaluation of the quality of the radio 
connection) , also in consideration of data stored 

20 on the SIM, 

evaluations 2 04 of end-to-end performance 
(terminal side or server side) , both operator 
driven (2 04a) and user driven (2 04b) , 

evaluations 2 06 of the performance of the 
25 terminal /server, also both operator driven (2 06a) 

and user driven (2 06b) , 

- verification 208 of SLA agreement at the terminal 
and service provider level, also both operator 
driven (208a) and user driven (208b) . 

30 The platform can also be used for troubleshooting 

functions, i.e. to identify possible causes of QoS 
degradation within the terminal. 
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This set of function, globally designated as 210, 
essentially comprises diagnostics and malfunction 
notification (terminal side, application server side) 
and real time configuration and management of resources 
5 (also terminal side and application server side) . 

The diagram of Figure 4 expressly indicates that 
said functions can be decided both by the operator 
(block 212) and by the user (block 214) . 

In the diagram of Figure 4, the blocks 220 and 230 
10 indicate the possible application of the platform to 
diagnose the internal resources and functionalities of 
the terminal and the optimised configuration and 
management of resources (e.g. in real time) in a 
Quality of Service (QoS) perspective. 

15 Briefly, the platform architecture described herein 

provides the ability to: 

- measure, simultaneously and globally in mobile 
radio environment in objective fashion and on a call- 
by-call basis, quality parameters and operating 

20 conditions of the link in the point of access to the 
service that is closest to the user's perception (hence 
on the terminal and at application level) , 

- measure not only the quality parameters of the 
session (availability, accessibility, link maintenance, 

25 delays, errors, losses on information contents) , but 
also simultaneously to detect the operating conditions 
of the radio channel (power, BER etc.), of the link 
(throughput) , of the terminal (CPU load, buffer and 
memory usage...), in which it was obtained, 

30 - associate terminal location data to the measure, 

- segmenting quality degradation between network/ 
terminal/ application server, 
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- transparently conducting, on the user terminal, 
measurements either in real traffic on the ongoing 
communication, or activating measurements in artificial 
traffic, 

5 - dynamically managing (also remotely) both the 

terminals on which the measurement is to be conducted, 
and the profile of the measurements (parameters, 
measurement procedures) , 

- conduct measurements both driven by the service 
10 provider and by the user, 

automatically manage the procedures for 
downloading, processing and locally storing the 
measurements (on the terminal) , according to the 
processing load of the terminal and of the radio 
15 channels, 

- achieving platform independence from network 
technology, 

- choosing the most suitable transport mode, among 
available ones (the one that will minimise impact on 

20 network load) for the communications between the 
platform agents. 

The platform described herein is suitable to 
monitor QoS also in advanced multi-standard 
environments (for example UMTS/W-LAN) in which a multi- 

25 mode intelligent terminal is able simultaneously to use 
multiple access systems for transporting information 
(communication formed by multiple parallel links on 
multiple radio systems) . 

The platform described herein for monitoring end- 

30 to-end QoS for services supported by mobile radio 
terminals can also be used by means of an ad-hoc 
development of the APIs (Application Program Interface) 
interfacing with the operating and development 
environment to fixed networks (LAN, MAN and WAN) and to 
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wireless networks (W-LAN) . Moreover, the platform can 
operate in mult i- standard environments on multi-mode 
terminals . 

In the currently preferred embodiment, the 
5 solution described herein provides a platform for 
monitoring QoS (both in real traffic and in artificial 
traffic) that is applicable to all services, to all 
mobile radio networks (GSM/GPRS/UMTS/EDGE) and to all 
mobile radio terminals (characterised by different 

10 operating environments, performance and interfaces) : 
the architecture is based on measuring agents located 
on the mobile terminals, able to interface, with 
appropriate APIs, with the processes for managing the 
application session, measuring radio reception 

15 conditions, status and operating condition (load, 
terminal location, etc.) and to dialogue with other 
measuring or management agents. These agents can be 
remotely and flexibly managed on the terminals 
according to measurement scheduling (they can be 

20 loaded, activated, configured dynamically on a 
predetermined set of mobile radio terminals) . 

They are also able: 

To carry out co-ordinated measurements 
(according to configurable measurement profiles) . 

25 - To carry out local storage/pre-processing 

operations as a function of operating conditions (e.g. 
load on the radio channels for transmitting the 
measurements, re-transmission requests from the 
collection centre) . 

30 - To manage the transfer of the measurement 

results to a collection centre in programmable fashion. 
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Through this architecture it is possible to carry 
out conventional operations (on the user terminal) , 
such as : 

- obtaining typical measurements of the quality 
5 and of the operating conditions of the radio access 

(transmitted or received power, BER, etc. . ..), 

monitoring end-to-end transport performance 
(both in real traffic and in artificial traffic) , 

- measurements and processing (on the mobile radio 
10 terminals) for the production of QoS indicators at the 

end-to-end application layer, and hence very close to 
the quality perceived by the users, which depend both 
on the type of service and on the service step of 
interest, such as: availability, accessibility, delays, 
15 jitter, losses, drops, etc. 

monitoring the operating conditions of the 
resources of the terminal and network (throughput, CPU 
load and memories, buffer congestion, etc.). 

Naturally, without altering the principle of the 
20 invention, the construction details and the embodiments 
may vary widely from what is described and illustrated 
herein, without thereby departing from the scope of the 
present invention, as defined in the appended claims. 


